…the code kind and the logic kind.
Let me briefly explain: coder’s block is a lot like writer’s block, except for programmers. You sit there staring at your screen, your hands hovering over the keys, mind ready to go at it — but nothing happens.
Why?
Here are the two reasons for, and kinds of, coder’s block:
1. Code jungle block
Hundreds of files. Tens of thousands of lines. Hundreds of thousands of variables. All necessary to the one feature you’re developing. After a while, your brain gets clogged, stuffed up with all the content you’re juggling in your head.
At some point, it’s simply too much! So that part of your brain shuts off for a while. You know what you’re trying to do, but the rest of the pieces of the puzzle simply refuse to move around any more; they’re tired.
How to solve:
Firstly, take a break! This kind of block is your mind’s way of telling you to chill out for a while and give yourself a mental refresh. Physical activity is useful here too, anything from a walk to a game of volleyball.
Secondly, see if you can take some time to clean up the code, or just look through it a bit without trying to code anything at all. A more relaxed, broad approach to your task can move mountains (or blocks).
2. Logic block
You’re pretty sure the solution you need to write is pretty simple. The code itself may be only a dozen lines long. But you have no idea how to get there. What exactly do the specs for your project mean? How should you interpret the vaguely-worded requirements? Confusion sets in and suddenly you’re paralyzed, trapped between the urge to work on and resolve this confounding issue and the need to back off of it and its complexities and let things sort themselves out in your head. Back and forth you bounce, making no real progress and growing increasingly stressed.
How to solve:
As before, take a break! But this time only to let your tension simmer down — here, you need to take very direct action. Talk to those who wrote the requirements, whether a client, manager, or developer, and get them to elucidate exactly what they need you to do. Talk to them in their language — a developer like a developer, a manager in objectives and goals, a client in business logic.
Communication is key, but it too has its limits — you’ll also need to sit down, re-read your requirements in light of the new information you’ve been given, and give it another stab. It’s daunting, but can be overcome. You’re a developer, and developers are problem solvers at heart.